Graphics system

ABSTRACT

A graphics system which accelerates generation of pixels including transparent objects by simply adding more rendering devices. The system has composition means and a plurality of rendering devices each comprising a geometric processor, a rendering processor and a frame memory that holds color, depth and weight data in a screen bit map format. Given a plurality of sets of color, depth and weight data about any one pixel position from the frame memories, the composition means first compares the depth data, and multiplies successively the weight and color data starting with those corresponding to the depth data closest to the foreground, thereby generating new pixel data. The system thus permits merging of transparent objects.

BACKGROUND OF THE INVENTION

The present invention relates to techniques for enhancing the speed ofgraphics processing performed on workstations, personal computers andthe like. More particularly, the invention relates to a graphics systemfor utilizing a plurality of rendering devices.

In a graphics system implemented by a workstation or the like, graphicsprocessing is accelerated conventionally by a setup comprising aplurality of geometric processors for performing geometric computationsin graphics, as well as a plurality of rendering processors forgenerating pixels. For example, a Z-merger image composition schemeinvolving a plurality of rendering devices to generate three-dimensionalimages parallel is used to increase the processing speed of “Subaru: AHigh-Speed High-Performance 3D CG System” which was discussed in theautumn 1992 symposium of the Institute of Electronics, Information andCommunication Engineers (proceedings, pp. 6-602-207). The disclosedsystem utilizes a plurality of rendering devices, each made up of ageometric processor, a rendering processor and a frame memory. On thelevel of pixels in which each rendering device effects its output, thesystem compares depth data (Z values) per pixel so that the color ofeach foreground pixel is selected. A final image is obtained by thesystem merging outputs from a plurality of rendering devices.

One advantage of the conventional technique mentioned above is that itis easy to shorten the time for image generation by simply adding morerendering devices, as discussed illustratively by Foley, van Dam, Feinerand Hughes in “Computer Graphics: Principle and Practice” (from AddisonWesley, pp. 906-907).

It should be noted that the disclosed system mentioned above with itsZ-merger scheme simply selects pixels during Z value comparison and doesnot generate new pixel data. This means that the system has difficultyevaluating in Z values any transparent object which lets light passtherethrough. In some cases, transparent objects are not adequatelydisplayed.

SUMMARY OF INVENTION

It is therefore an object of the present invention to overcome the aboveand other deficiencies of the prior art and to provide a graphics systemwhich boosts the speed of processing on transparent objects by simplyadding more rendering devices and which addresses high-performancerendering functions, such as shaded, rendering while maintaining thehigh-speed processing capability.

In carrying out the invention and according to one aspect thereof, thereis provided a graphics system comprising: a plurality of renderingdevices each including a first processor for generating renderingcommands, a second processor for distributing the generated renderingcommands, a frame memory for holding color, depth and weight data inincrements of pixels in a screen bit map format, a third processor forexecuting the distributed rendering commands to write the color, depthand weight data about each pixel to the frame memory; and compositionmeans for composing contents of the frame memories included in therendering devices, the composition means further outputting the composedresult to a display device; wherein the composition means performsarithmetic operations using depth and weight data about any one pixelposition (i.e., pixels corresponding to the same X and Y coordinates)read from the frame memories of the rendering devices so as to generatenew pixel data about that pixel position, the composition means furtheroutputting the generated new pixel data to the display device.

Preferably, the composition means may be constituted by arithmeticcompositors. Given a plurality of sets of color, depth and weight dataabout the pixels corresponding to the same X and Y coordinates from theplurality of frame memories, the compositors first compare the depthdata of the multiple data sets. Regarding the figure closest to theforeground, the compositors multiply the weight and color dataassociated therewith; and for the next-closest figure, the compositorsmultiply the applicable weight and color data and add the product tothat of the preceding figure, and so on. The compositors continue theproduct accumulation until the weight data becomes zero.

More specifically, the inventive graphics system may further comprisesecond frame memories for accommodating the output of the arithmeticcompositors. The output of the second frame memories is used as an inputto the arithmetic compositors.

As outlined and according to the invention, the arithmetic compositorsin their accumulation process compare depth data one pixel at a time,multiply color data about each object, starting with the one closest tothe foreground, by the corresponding weight data, and add up productsfrom the multiplication. When the weight data include valuesrepresenting transparency of objects, it is possible to compose suchtransparent objects on the screen.

In a setup comprising the second frame memories to hold the output ofthe arithmetic compositors so that the output of the second framememories may be used as an input to the arithmetic compositors, thesecond frame memories amount to an accumulated frame memory arrangementfor accommodating compositor outputs. This means that the number ofaccumulation iterations may be increased even where the number ofrendering devices is limited.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of an arithmetic compositor;

FIG. 2 is an overall block diagram of a system representing anembodiment of the invention;

FIG. 3 is a block diagram of a current weight computing unit in thearithmetic compositor shown in FIG. 1;

FIG. 4 is an overall block diagram of a system representing anotherembodiment of the invention;

FIGS. 5A and 5B are is a schematic diagrams showing how transparentobjects are rendered illustratively according to the invention;

FIGS. 6A to 6C are is a schematic diagrams depicting how shadedrendering is carried out illustratively according to the invention; and

FIGS. 7A to 7D are is a schematic diagrams indicating how volumerendering is conducted illustratively according to the invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the present invention will now be described withreference to the drawings.

FIG. 2 is an overall block diagram of a graphics system representing onepreferred embodiment of the invention. Inputs from a keyboard 5 areconverted to signal form by a controller 4, and the resulting signalsare sent to a CPU 1. Given the signals, the CPU 1 carries out diversecontrols and allows application programs to perform their processesaccordingly. When an image is to be displayed on a monitor 9, the CPU 1generates graphics commands that are transmitted over a system bus 1001to a graphics subsystem 91.

The graphics subsystem 91 comprises a plurality of independent renderingdevices 10 through 13, arithmetic compositors 100 through 102 forcomposing images generated by the rendering devices 10 through 13, acolor look-up table 7 including a table for correcting color data fromthe last-stage arithmetic compositor 102, a DAC 8 for digital-to-analogconversion, and the monitor 9.

Each rendering device (e.g., rendering device 10) comprises a geometricprocessor 60, a rendering processor 70 and a frame memory 80. Thegeometric processor 60 performs geometric computations such as figurecoordinate translation and brightness calculation in graphicsprocessing. The rendering processor 70 generates a figure throughpixel-by-pixel interpolation inside the figure based on the output fromthe geometric processor 60. The frame memory 80 retains the result ofcomputations from the rendering processor in increments of pixels. Thatis, the frame memory 80 holds color, depth and weight data per pixel.Illustratively, the frame memory is composed of 24 bits foraccommodating color data, 16 bits for depth data and 8 bits for weightdata per pixel.

The geometric processor 60 sets function level commands for eacharithmetic compositor through a command setting signal line 1004.

The CPU 1 transmits graphics commands to the rendering devices 10, 11,12 and 13, in that order on a time series basis. Given a graphicscommand, each rendering device generates an image corresponding to thatcommand. As disclosed in Japanese Patent Laid-Open No. Hei 5-266201,graphics attribute commands are necessary for all rendering devices andare thus broadcast thereto during operation.

For parallel processing to be performed by the rendering devices, ascreen divided scheme may be used. Specifically, the CPU 1 assigns ascreen area to each of the rendering devices configured. Graphicscommands are broadcast to all rendering devices. Upon receipt of agraphics command, each rendering device generates an image in the screenarea assigned to the device in question as designated by the receivedcommand. A value of 0 is set as weight data for pixels outside thescreen area assigned to each rendering device. Using such weight datamakes it easy to implement screen divided processing.

The images generated by the rendering devices 10 and 11 are sent to thearithmetic compositor 100. In turn, the arithmetic compositor 100composes the received color, weight and depth data from the renderingdevices 10 and 11 into new color, weight and depth data per pixel. Thenewly generated data are transferred to the next arithmetic compositor101. What takes place in the arithmetic compositor 100 is illustrated inFIG. 1. For its part, the arithmetic compositor 101 composes thereceived color, weight and depth data from the arithmetic compositor 100and rendering device 12 into new color, weight and depth data per pixel.The newly generated data are transferred likewise to the next arithmeticcompositor 102. The process is repeated for the rendering devices tocompose images successively. When the image from the last renderingdevice 13 is subjected to composition, the final image is acquired.

The final image is subject to color correction such as gamma correction,by the color look-up table 7. The corrected image is sent to the DAC 8.The DAC 8 converts the received image into analog signals that arecompatible in format with the monitor 9. The converted signals aretransmitted to the monitor 9.

A synchronizing signal line 1002 is provided. This is a signal line thatcarries synchronizing signals for synchronizing the transmission ofsignals from each rendering device to the corresponding arithmeticcompositor as well as for ensuring synchronism between the DAC and themonitor.

FIG. 1 is an internal block diagram of the arithmetic compositor 100.The arithmetic compositor 100 receives as its input two sets of colordata (COLOR-IN), weight data (WEIGHT-IN) and depth data (DEPTH-IN) perpixel; and, the compositor 100 composes the two sets of input data intonew color data (COLOR-OUT), weight data (WEIGHT-OUT) and depth data(DEPTH-OUT).

As initial values, a wt.min register 115 and a wt.max register 116 holda maximum and a minimum value respectively designating an effectiverange of weight data. The values are set by means of the command settingsignal line 1004.

A comparator 111 compares depth data DEPTH-IN 0 with depth data DEPTH-IN1, and supplies a switcher 114 with a signal indicating which of thecompared pixels is the closer to the foreground. If the two comparedpieces of depth data turn out to be the same, a signal line 1011notifies current weight computing units 122 and 132 of the two comparedpixels having the same depth. At the same time, the arithmeticcompositor 100 outputs DEPTH-OUT, i.e., a signal representing theDEPTH-IN data about the pixel near the foreground. Under the instructionof the comparator 111, the switcher 114 rearranges the input color andweight data so as to forward to a block 112 the COLOR-IN and WEIGHT-INdata about the pixel closer to the foreground.

The block 112 performs arithmetic operations on the near-foregroundpixel and sends the result to a block 113. The block 112 comprises thecurrent weight computing unit 122, a multiplier 121 and an adder 123.Given the weight data from the switcher 114, the current weightcomputing unit 122 checks the values in the wt.min register 115 andwt.max register 116 to see if the data falls within the acceptable rangeof weight data. After operating on the current weight data, the currentweight computing unit 122 sends the result to the multiplier 121. Theweight data accumulated so far is forwarded to the next block 113. Thecurrent weight computing unit 122 will be described later in more detailwith reference to FIG. 3.

The multiplier 121 multiplies the received current weight data by thecorresponding color data. The product from the multiplication istransmitted to the adder 123. The adder 123 adds the current color datato the preceding color data in effect so far. The sum is sent to thenext block 113. Since the color data in effect so far is zero for theadder 123, the block is wired to ensure that the preceding color data isalways zero.

The block 113 is a block that operates on the data that is the fartherof the two sets of data relative to the foreground. What takes place inthe block 113 is the same as in the block 112, except that the currentweight computing unit 132 outputs weight data WEIGHT-OUT and an adder133 outputs color data COLOR-OUT. This is where the color and weightdata are accumulated.

FIG. 3 is an internal block diagram of the current weight computingunit. Comparators 212 and 211 and an AND circuit 213 check to see ifdata “wtnear,” i.e., weight data near the foreground, falls into theeffective range of weight data. A signal reflecting the result of thecheck is sent to a selector 214. The selector 214 allows the data“wtnear” to pass through if the data is found to be within the effectiverange. If the data “wtnear” is found to be outside the effective range,the selector 214 outputs zero. Comparators 216 and 215 and an ANDcircuit 217 perform the same operation on data “wtfar,” i.e., weightdata far from the foreground.

A subtracter 202 subtracts the output of the selector 214 from the valuein the maximum value register 201, and transmits the difference to amultiplier 203. The multiplier 203 multiplies the output of the selector218 by the output of the subtracter 202, and sends the product to aselector 204. The selector 204 selects the output of the selector 218 ifa Z_equal signal on the signal line 1011 is effective; the selector 204allows the output of the multiplier 203 to go out if the Z₁₃ equalsignal is invalid, i.e., if the depth data is different. The output ofthe selector 204 becomes a signal “wtcurr” that is placed onto a signalline 1013. An adder 205 adds the outputs of the selectors 214 and 204 inorder to accumulate the weight data. The output of the adder 205 is sentas a signal “wtout” onto a signal line 1014.

The described above are summarized by expressions (1) through (4) givenbelow. That is, the weight data near the foreground is given priority,and the remaining weight of the near-foreground weight data ismultiplied by the weight data about the pixel far from the foreground toprovide current weight data about the faraway pixel data. Adding up theweight data on the near and far pixels provides weight data combiningthe near and far data.

(a) When Z_equal is not effective (when depth data is different)

wtout=wtnear+(1−wtnear)×wtfar  (1)

wtcurr=(1−wtnear)×wtfar  (2)

(b) When Z_equal is effective (when depth data is the same)

wtout=wtnear+wtfar  (3)

wtcurr=wtfar  (4)

where, subscripts “near” stand for data on the near pixel and “far” fordata on the far pixel.

The current weight computing units executing the above expressions areused by the arithmetic compositors that perform operations representedby expressions (5) through (10) below.

(a) When Z_equal is not effective (when depth data is different)

Cout=Cnear+WTnear+Cfar×(1−WTnear)×WTfar  (5)

Zout=Znear  (6)

WTout=WTnear+(1−WTnear)×WTfar  (7)

(b) When Z_equal is effective (when depth data is the same)

Cout=Cnear+WTnear+Cfar×WTfar  (8)

 Zout=Znear  (9)

WTout=WTnear+WTfar  (10)

where, C stands for color data. If WT.min>WT or if WT>WT.max, thenprocessing proceeds on the assumption that WT=0.

The graphics subsystem using the arithmetic compositors functioning asdescribed above obtains the final image by performing arithmeticoperations successively on the images rendered by the rendering devices10 through 13 shown in FIG. 2.

FIG. 4 is an overall block diagram of a system representing anotherembodiment of this invention. The components of the embodiment arebasically the same as those of the embodiment in FIG. 2, except that aframe memory 89 and a signal line 1003 stemming from that memory areadded. There is no significant difference between the two embodimentsbecause the number of rendering devices can be readily increased byadding more arithmetic compositors in a similar setup. The frame memory89 holds the output of the last-stage arithmetic compositor 102. Theoutput of the frame memory 89 is placed onto the signal line 1003 andinput again to the frame memory 82 of the rendering device 12. Thisallows the final image to be further edited or computed by use of thefunction of the rendering device 12. When the output of the frame memory89 is input via the signal line 1003 to the arithmetic compositor 100,it is possible to superimpose the final image in the frame memory 89repeatedly onto the images rendered by the rendering devices 10 through12. The operations involved are synchronized by the signal from thesignal line 1004.

FIGS. 5A through 7D depict some high-performance rendering exampleseffected according to the invention.

Specifically, FIG. 5A shows an image including transparent objects, inwhich it is assumed that the viewpoint is on the Z axis (Z=+∞) anddirected toward the point of Z=0. It is also assumed that spheres 300and 301 with a transparency of 0 each, i.e., with a weight of 1.0 andrectangular prisms 302 and 303 with a transparency of 30% each, i.e.,with a weight of 0.7, are laid out as indicated.

Below is a description of a typical rendering procedure using the systemof FIG. 2. The CPU 1 generates graphics commands representing theobjects shown in FIG. 5A and sends the generated commands to thegraphics subsystem 91. The graphics commands representing the spheres300 and 301 with the transparency of 0 each are transmitted to therendering devices 10 and 11 respectively. The graphics command denotingthe rectangular prism 302 with the transparency of 0.3 is sent to therendering device 12, and the command representing the rectangular prism303 with the transparency of 0.3 is forwarded to the rendering device13.

In response, the rendering device 10 renders the sphere 300 and placesthe image data about the sphere 300 into the frame memory 80 thataccumulates the image data on the sphere 300. Likewise, the renderingdevices 11, 12 and 13 cause the image data on the sphere 301 andrectangular prisms 302 and 303 to be accumulated respectively. Thearithmetic compositor 100 composes the image data on the spheres 300 and301. Because the two spheres 300 and 301 have weight data of 1.0 each,only the color data about the sphere near the foreground is selectedwhere the two spheres are overlaid.

The arithmetic compositor 101 composes, through arithmetic operations,the composed image data on the two spheres and the image data about therectangular prism 302. Because the rectangular prism 302 is locatedfarther than the sphere 300, the image data about the sphere 300 isselected unmodified. The selected data corresponds to an area 400 inFIG. 5B.

Outlined below with reference to FIG. 1 is typical processing regardingan area where the sphere 301 and rectangular prism 302 are overlaid(i.e., area 404 in FIG. 5B. The comparator 111 compares the depth datainvolved and judges that the rectangular prism 302 is closer to theforeground than the sphere 301. Given the judgment, the switcher 114sends the color and weight data about the rectangular prism in front tothe block 112 that computes the color of the near-foreground object, andtransmits the data about the faraway sphere 301 to the block 113. Sincethe weight data on the near pixel is always zero for the current weightcomputing unit 122, the weight data of 0.3 about the rectangular prism302 is output unchanged over the signal lines 1013 and 1014. Themultiplier 121 multiplies the color data having the transparency of 0.3by the color data about the rectangular prism, and sends the product tothe adder 123. The adder 123 outputs its input unmodified to the adder133. The current weight computing unit 132 receives and computes theweight data of 0.3 about the near object and the weight data of 1.0about the faraway sphere 301. The resulting weight data of 0.7 is sentto the multiplier 131. In turn, the multiplier 131 multiplies the weightdata of 0.7 by the color data of the sphere, and forwards the product tothe adder 133. The adder 133 adds up the result from multiplying theprism color by 0.3 and the result from multiplying the sphere color by0.7, and outputs the sum that is color data COLOR-OUT.

Although the example of FIG. 5A has been described using areas, theprocessing of the arithmetic compositors 100 through 103 actually takesplace one pixel at a time.

The final image, shown in FIG. 5B, reflects the depth and transparencydata involved. Illustratively, the areas 400 and 401 directly reflectthe spheres only, while the area 404 reflects the sphere 301 behind atransparent prism.

FIGS. 6A to 6C are is a schematic diagrams depicting how shadedrendering is typically carried out according to the invention. How thisrendering is performed will now be described, followed by a descriptionof how the graphics system of the invention illustratively implementsthe rendering. The objects to be rendered here are triangles 500 and 501as well as a rectangle 502, shown in FIG. 6A.

Initially, how the target objects look from a light source is evaluated.The evaluation is carried out by writing, pixel by pixel, the distancebetween the light source and a given object to a distance buffer. Atthis time, as in the case of common Z buffer write control, it mayhappen that a distance at which a pixel is written to the distancebuffer and another distance of the same pixel is again written to thebuffer. In that case, the content of the distance buffer is updated ifthe value to be written represents a position closer to the light sourcethan the currently retained distance; and, the Z buffer value is leftunchanged if the value to be written represents a position farther thanthe light source. Eventually, only areas visible from the light sourceare written in the distance buffer. The eventual image data in thedistance buffer is shown schematically in FIG. 6B. As illustrated, partof the object 500 is hidden behind the object 501. The hidden portion isan area 504.

Next, a common method of rendering relative to a viewpoint is used toperform color computations regarding a single light source whilerendering the result onto a color plate. At this point, the position ofthe light source and the distance to the target object are calculatedsimultaneously per pixel. The distance computed this time is comparedwith the value held in the distance buffer reflecting the layout in FIG.6B. If the compared distances are found to be different, the pixel inquestion is not affected by the light source. In that case, the writingof color data is masked and nothing is reflected on the color plane. Ifthe compared distances turn out to be the same, the result of ordinarylight source computations under the influence of the light source iswritten to the color plane.

Illustratively, while the object 501 is being rendered, the entireobject 501 represents an area visible from the light source. It followsthat the color data which has undergone the light source computations iswritten to the color plane. In this case, a common Z buffer feature ofshade erasure furnishes image data in which the object 502 issuperimposed on the object 501. When the object 500 is being rendered,the distance buffer accommodating the area invisible from the lightsource (i.e., area 504) retains the distance of the object 501 in thelayout of FIG. 6B. This means that comparing the distance buffercontents leads to a difference in distance. This causes the maskingfunction to act on the write operation to the color plane, therebypreventing color data from being written to the color plane. As aresult, an area 508 is shown shaded.

The processes in FIGS. 6B and 6C are conducted relative to a singlelight source. These processes are repeated as many times as the numberof light sources configured. Then the color results of brightnesscomputations regarding all light sources are added up to provide finalimage data.

One typical shade rendering method has been described above. This shaderendering method may be implemented by the graphics system of FIG. 2having one light source assigned to each of the rendering devicesconfigured. For example, the rendering device 10 causes the frame memory80 to hold image data relative to one light source. The rendering device11 causes image data relative to another light source to be retained. Inthis manner, the image data acquired relative to the light sourcesinvolved are composed by the arithmetic compositors. In this case, therendering devices share the processing of color computations relative toall light sources. That is, all rendering devices process each of theobjects to be rendered. This means that the depth and weight data arethe same for every rendering device. It follows that the Z_equal signalon the signal line 1011 becomes effective for all pixels. This causesthe selector 204 in FIG. 3 to select the output of the selector 218. Theoperations involved are represented by Expressions (3), (4), (8), (9)and (10). If all weight data is 1.0, then the operations involved aresimply additions.

FIGS. 7A to 7D are shematic diagrams showing how the invention isillustratively applied to a volume rendering scheme having a pluralityof cross-sectional images of an object rendered as viewed from a givenviewpoint. How the volume rendering scheme is generally performed willbe described below, followed by a description of how this volumerendering is applied to the inventive graphics system. It is assumedthat there are a plurality of cross-sectional images 601 through 604(FIG. 7B) of an elliptic sphere 600 (FIG. 7A) and that areas 641 through643 have a weight of 0.8 each and areas 644 through 647 have a weight of0.1 each.

Image data 611 through 614 indicate in FIG. 7C how the cross-sectionalimages 601 through 604 are seen laterally. In this application, theimage data 611 through 614 are projected onto a plane 631. Image data621 through 624, as seen in FIG. 7D are identical to the image data 611through 614.

One way of implementing this application involves setting up aprojection plane 632 apart from the projection plane 631. The image data611 through 614 are shifted in such a manner that the image data willintersect the projection plane 632 perpendicularly, whereby the imagedata 621 through 624 are provided. With the image data projected in thismanner onto the plane 632, the projection plane 632 is converted toanother projection plane 633.

To apply the above volume rendering scheme to the graphics system ofFIG. 4 involves assigning one cross-sectional image to each of therendering devices configured. For example, the cross-sectional images601 through 604 are assigned to the rendering devices 10 through 13,respectively. The image data 621 through 624 are generated by eachrendering device shifting the image data 611 through 614 in a way thatthe image data will intersect the projection plane 632 perpendicularly.Image data projection onto the projection plane 632 is carried out bythe arithmetic compositors. The result is held temporarily in the framememory 89. The projection plane 632 is then converted to the projectionplane 633. To execute the conversion requires first transferring theoutput of the frame memory 89 to the frame memory 83 over the signalline 1003, and then having a rendering processor 73 perform theconversion processing involved.

It is easy to display only the areas 641 through 643 in the aboveapplication. Specifically, the weight of 0.5 for the areas 641 though643 need only be set in the wt.min and wt.max registers by use of thesignal line 1004, and the rest of the processing is the same.

The above scheme allowing the effective range of weight data to be setusing the wt.min and wt.max registers is effective in extracting andrendering the interior of objects. In that case, however, the originalcolors are attenuated by weight data. The color attenuation is correctedby means of the color look-up table 7. Signal lines for setting thecolor look-up table 7 are not characteristic of this invention and arethus omitted.

Furthermore, at rate at which to monopolize one pixel for weight datamay be retained. This scheme is effective in implementing antialiasingtechniques.

Antialiasing of high precision may be implemented at a limited sacrificeof performance. For example, images may be created by rendering throughpixel-by-pixel parallel translation performed longitudinally andcrosswise by the rendering devices. One fourth of the maximum weight ineffect may be set as weight data. The arithmetic compositors thenmultiply the image data from each rendering device by one fourth. Thisprovides antialiasing of an enhanced precision level.

What is claimed is:
 1. A graphics system comprising: a plurality ofrendering devices each including a first processor which generatesrendering commands, a second processor which distributes the generatedrendering commands, a frame memory which holds color, depth and weightdata in increments of pixels in a screen bit map format, and a thirdprocessor which executes the distributed rendering commands to write thecolor, depth and weight data about each pixel to said frame memory; andcomposition means for reading said color data, depth data and weightdata for each pixel from each said frame memory and generating new colordata and new weight data from the color data and the weight data of asame pixel position based on the depth data, said composition meansreading said color data, depth data and weight data from said framememory in synchronization with outputting generated new color data andnew weight data to a display device.
 2. A graphics system according toclaim 1, further comprising second frame memories for accommodating saidnew pixel data generated by said composition means, the pixel data insaid second frame memories being read for input to said compositionmeans.
 3. A graphics system according to claim 1, further comprisingsecond frame memories for accommodating said new pixel data generated bysaid composition means, and transfer means for transferring the pixeldata from said second frame memories to the frame memory of each of saidrendering devices.
 4. A graphic system comprising: a CPU which generatesa plurality of rendering commands; a plurality of rendering devices,each rendering device including: a rendering processor which executesrendering commands and generates color data, depth data, and weight dataabout each pixel, and a frame memory, the frame memory storing saidcolor data, said depth data and said weight data; and composition meansfor reading said color data, depth data and weight data for each pixelfrom each frame memory and generating new color data and new weight datafrom the color data and the weight data of a same pixel position basedon the depth data, said composition means reading said color data, depthdata and weight data from said frame memory in synchronization withoutputting generated new color data and new weight data to a displaydevice.
 5. A graphics system according to claim 4 or 2, wherein, given aplurality of sets of color, depth and weight data about any one pixelposition from said plurality of frame memories, said composition meansfirst compares the depth data, multiplies successively the weight andcolor data starting with those corresponding to the depth data closestto the foreground and accumulates products from the multiplication,thereby generating new pixel data.
 6. A graphics system according toclaim 4 or 2, wherein, given a plurality of sets of color, depth andweight data about any one pixel position from said plurality of framememories, said composition means generates new pixel data using theweight data provided said weight data exists within a predeterminedrange.